pbio/platform/ev3: Enable more storage and heap. #392
Conversation
Yes, we really don't want a huge heap because of this. MicroPython now has some support for multiple heaps, so if we want the best of both, we could have a smallish heap and if that runs out, add a 2nd heap and so on. So if someone wanted to do something really RAM intensive, the could, but will pay the penalty in performance. And as always, we should do some measurements to make sure those assumptions are correct. Where we store user code can be a big number though since the GC doesn't have to scan that since we are executing directly from MPY. So we will probably want to do things a little differently than having a single RAM area for both like we do on other hubs. |
|
Thanks. Any particular suggestion for heap size to get started with initially? |
|
Hmm... looks like we had 8MiB on Pybricks v2.0. pybricks/micropython@ecbd58a So maybe the performance hit wasn't so noticeable with the faster processor? We could try it and try to measure how long a GC cycle takes. Just gut feeling, I think a 1MiB size might be more reasonable. |
This bare metal EV3 version has more resources than we know what to do with. We'll start with relatively small values, about four times as much as SPIKE Prime has.
This still applies, but there is no longer a cross platform way to check it.
laurensvalk
force-pushed
the
ev3-heap
branch
from
9aae94c to
aae6462
Compare
|
Sounds good. I submitted 4MiB originally, but now updated to 1MiB. Either value should work better than the 10K placeholder value we had. |
Opening this for discussion. @dlech @ArcaneNibble. Anything we should be aware of? Should we just max it out instead of picking these small values (though still far larger than SPIKE Prime).
I suppose garbage collection will happen later but take more time this way. We've previously added hooks to upstream MicroPython to drive our event loop during garbage collection. But user code will block during collection.